The invention relates to rich-desktop client middleware, such as IBM® Workplace™ Client Technology, which moves beyond the browser, enabling not only browser capabilities, but also the ability to securely and incrementally download, update, and intelligently cache the next generation of “rich” and hybrid client applications. These applications run locally on the end user's machine using an encrypted, synchronized content store with security features and offline/disconnected capabilities. Such applications harness the full power of the user's machine to deliver increased capability and performance while continuing to be centrally deployed, upgraded, and administered at the server, side by side with browser-based applications.
The environment in which such client middleware is intended to be used comprises a plurality of centrally managed rich clients and a policy-based client provisioning server, such as a secure enterprise-wide portal. Initial installation of applications as well as maintenance updates can be applied on a managing server and experienced dynamically by users client-side. The applications or updates are automatically provisioned to clients from the managing server under the control of an administrator.
The clients are managed through the use of administration policies defining the capabilities, applications and information, which are available to specific sets of users. For example, a policy called Marketing Group could be configured to define the capabilities that will be supported for users within the enterprise who are defined in that category. Within that policy, an administrator can specify which client applications should be available to those users. For example, an administrator could specify that Mail, Calendar, Document Management, and Discussions applications be dynamically provisioned for the Marketing Group but not a Human Resource application.
The rich client technology works on the basis of concepts first developed for portals for creating component-based Web applications. In a portal, components called portlets generate markup fragments that are aggregated by a portal server into a composite portal page. In a rich client, plug-ins generate views that are built into a client page for display by the rich client. In other words, an application can be represented, on a client platform, in a rich-client-specific presentation layer, by one or more plug-ins; and, on a portal server, in a portal-specific presentation layer, by one or more portlets. The client platform and the portal server each have distinct UI implementations but share a common layer of logic for accessing service components.
A rich client application is represented by a portal page on the portal server. The portal page has a tabular layout with each cell displaying content provided by a portlet. The configuration for each portlet defines the associated client view. The portlets support a rich client ‘markup language’ as a markup type and produce a description of the contents and parameters of the associated client view.
Configuration and page assembly by a rich client are driven by the managing portal server. When a user requests a portal page via a rich client, the portal server aggregates the content from those portlets on the requested page to which the user has authorised access into a document in the client-requested type of markup. The portal server then provisions the rich client with this document which describes how the rich client should configure itself and assemble the page. The rich client uses the description to build a page from its view plug-ins.
This process of provisioning a client application by a portal server and the dynamic page assembly process is shown in FIG. 1. The client computer system 8 has installed thereon a rich client 10 comprising Application Manager (AM) 22, update manager 24, page builder 26, RCPML cache 28, and plug-ins 30, and a service request mechanism 32. The portal server 14 has a plurality of portlets P, a portal page aggregator 16 and an update server 18.
When a user 50 wishes to logon, the AM sends 101 the client user's name and password for a pre-established portal account to the portal server for authentication. A sign-on token is passed back 102 to the AM, as the result of a successful logon, for use in subsequent communication with the portal.
On first sign-on the AM will send an HTTP request to the portal server 14 for a list of applications which are available to the user, the request will specify the type of markup required, such as an XML (extensible Markup Language)-based rich client platform markup language (RCPML). The server will return a response listing Uniform Resource Locators (URLs) for use by the rich client to request pages representing rich client applications.
When a user selects a particular application from the list, the AM requests 103 the page from the portal using a URL to the portal page of the selected application. The portal server determines the portlets to which the authenticated user has access and aggregates the markup fragments that those portlets produce according to the page layout. The page aggregator 16 then emits 104 an RCPML document describing the plug-ins/views required to create the requested application page, along with the location at which they may be found and the configuration and layout of the views on the page.
Next, the Application Manager parses the markup received, determines the components required, and if necessary queries 105 the update manager, which is used to retrieve 106, 107 component configuration data sets for any missing or updated components from the update server 18.
When all required components are present, the Page Builder 26 aggregates the views specified in the received markup and renders the client page. Each view/plug-in 30 may connect 108 with services 20, as described in the received markup language document, for access to relevant data. The constructed page 40 is then presented 109 to the end user for interaction.
The client has a local secure data store 34 and an RCPML cache 28. When running in disconnected mode (i.e. offline from the portal server) the client uses this local cache of RCPML pages and previously loaded plug-ins for the applications rather than looking to the server.
Currently, the process to develop a new rich client application and deploy that new application to the portal server is complex, tedious and error prone, and requires that the developer have access to the portal server. Many manual steps are involved before a developer can see an application run, and the developer needs to be connected to the portal server. Referring to FIG. 2, the developer must create 200 Java™ for any new views required for the new application. Then the developer must connect 202 to the portal server, and create 204 a portal page, including installing portlets 206 for each view of the new application into the portal server's registry, and configuring each portlet on the portal page to refer to its associated view. The individual view plug-ins must be exported 208 onto a web server so that rich clients can access them. Then, the developer must launch 210 the rich client platform on a computer system, so that the rich client can be provisioned 212 by the portal server with the new application in client platform markup language. Finally, the rich client builds 212 the client page and the developer can see 214 the new application running. This long tedious process is detrimental to the productivity of a programmer trying to create an application. Also a developer requires an extensive knowledge of the server technologies in order to be able to produce a running application. Moreover, if the developer wishes to modify the new application, for example to change the layout and add views, the developer must reiterate through the steps described in FIG. 2, updating the previously selected page layout 204, creating and configuring portlets 206 for any new views, updating plug-ins on web server 208 and completing steps 210, 212, 214 and 216 to see the updated application running.
The invention aims to address these problems.